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NOTICE 


slogin: is the offical newsletter of the USENIX Association. ;login: is sent free of charge to indivi- 
dual and institutional members of the Association. The USENIX Association is a not-for-profit cor- 
poration incorporated under the laws of the State of Delaware. The officers of the Association are: 


President Lou Katz Directors John Donnelly 
Vice-President Peter Weiner Ira Fuchs 
Secretary Lew Law Debbie Scherrer 
Treasurer Mel Ferentz Wally Wedel 


The USENIX Association is an organization of AT&T licensees and sub-licensees formed for the 
purpose of exchanging information and ideas about the UNIX” operating system and the C program- 
ming language. Membership information can be obtained from the offices of the Association at 

USENIX Association 
Rockefeller University 
Box 8 

1230 York Avenue 
New York, NY 10021 
212-570-8934 


The Association can also be reached electronically at ucbvax!g:usenix. 


This newsletter may contain information covered by one or more licenses, copyrights, and/or 
non-disclosure agreements. Permission to copy without fee all or part of this newsletter is granted to 
Institutional Members of the USENIX Association provided that copies are made for internal use at the 
member campus or plant site. 





The next meeting of the USENIX Association will be a joint meeting with /usr/group. It will be 
held July 6-9, 1982, at the Copley Plaza Hotel in Boston. Subsequent meetings are scheduled for Janu- 
ary, 1983, in San Diego and June, 1983, in Toronto. 


“UNIX is a trademark of Bell Laboratories 
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Summary of the USENIX Association Board of Directors Meeting 


February 1, 1982 


To: Members of USENIX 
From: Lew Law, Secretary of USENIX 
Subject: Report on the Board meeting held Jan 26, 1982, 
continuing on Jan. 29, 1982 
Present: Katz, Weiner, Donnelly, Ferentz, Fuchs, Law, Scherrer, and Wedel 


The following invitees were present: Judy DesHarnais of ISC, Local Arrangements Chairwoman; 
Suzanne McNary, Local Arrangements Chairwoman for the Boston meeting being hosted by BB&N; 
Bob Lummis, Chairman of the Nominating Committee; nominees Bruce Borden, Tom Ferrin, Alan 
Nemeth, and Brian Redman. 


The quarterly meeting of the Board of Directors of the USENIX Association was held in conjunc- 
tion with the Winter Technical Meeting at the Miramar Hotel, Santa Monica. The meeting was brought 
to order at 6:30pm, Tuesday, January 26th, 1982. The purpose of the meeting was firstly to review any 
problems remaining in the arrangements for the technical meeting just starting; secondly to plan for the 
next technical meeting to be held in Boston in July and thirdly to deal with other administrative and 
business items. 


Judy DesHarnais, the Local Arrangements Chairwoman, had things well in hand. There were 
some minor problems needing attention, such as the production of the list of attendees for the Software 
Tools meeting, but nothing major. Conventions West, an organization hired to take care of some of 
the technical aspects of the meeting, in particular the Vendor Exhibit, had provided excellent service. 
Vendor exhibition space was considerably over-subscribed, but was limited by availability of space. 


The tutorial sessions were heavily over-subscribed, being limited to 25 participants each. It was 
hoped to get more feedback from the attendees, other than a general impression that the tutorials had 
proceeded smoothly. Lou Katz said there was some feeling among the conference attendees that the 
conference program should be available and distributed before the meeting. John Donnelly thought 
this would be very difficult to do, given the problems of organizing the program. 


Donnelly then requested that the next item on the agenda be the Boston meeting. Donnelly and 
Law had attended the /usr/group meeting in Boston in December, where there seemed to be great 
interest in holding joint meetings with USENIX. Law and Donnelly approached representatives of 
/usr/group to explore the situation, from which came the feeling that it would probably be a good idea 
to try this in Boston. Unfortunately the Monday of the week of the meeting is a holiday, as July 4th 
falls on a Sunday. This could cause some problems with scheduling. 


There was feeling on the part of some Board members that because of the time constraint, the 
joint meeting should not take place in Boston, but maybe at one of the following meetings. There was 
considerable discussion of the pros and cons, followed by a motion proposed by Ferentz that the Board 
go on record as being in favor of cooperation with /usr/group. The big problem was how soon the 
cooperation should start. The final decision hinged upon Donnelly’s assertion that he thought a com- 
mitment had been made, and his credibility and usefulness would be severely impaired if the commit- 
ment was withdrawn. 

A motion put forth by Katz was finally passed to form a committee to meet with representatives 
of /usr/group to discuss possible cooperation at the Boston meeting. Donnelly, Scherrer and Nemeth 
were appointed, and charged to report back to the Board on the following Friday (Jan. 29th), the last 
day of the meeting. 

Various other items were then dealt with. The timetable for election of the Board which will take 
office after the next technical meeting was set as follows: 


2/15/82 Call for further nominations to be mailed 
3/26/82 Nominations closed 
S/ 1/82 Ballots compiled and printed 
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§/15/82 Ballots mailed to members of good standing as of 5/15/82 
6/15/82 Last return date for ballots. 


The agenda for the USENIX Business session the following morning, and for the meeting of the 
attendees with the Board were discussed and set. Minutes of the preceding Board meeting were 
adopted following some amendments. 


Ferentz, as Treasurer, presented a Financial and Membership report for the year ending 
November, 1981. There were 265 Institutional members and 289 Individual members. Net assets have 
increased with the increase in membership. These assets are needed to provide working capital, such as 
the $26K which has already been advanced to cover expenses for the Santa Monica meeting and the 
Boston meeting. Motions were made and passed to receive the Treasurers report and to authorize an 
audit and generation of tax returns. 


Wedel reported that he had no time available for editing material for the newsletter, estimating 
that at least one day per week was required. There was some discussion as to the frequency with which 
the newsletter should appear, but it was inconclusive. Katz stated he would produce the January, 1982, 
newsletter, which will include a summary of the conference. Katz said that if he personally could not 
get this done he would take other measures to ensure publication. Tom Strong had been retained to 
take notes of the sessions, get copies of the viewgraphs and edit the result. 


Distribution tapes of the material submitted at the Austin Conference are going out. AT&T 
requires that we verify all licenses. In cases where we do not have positive evidence of licenses in the 
New York office we have written the members for copies of their licenses. Ferentz reported that 100 
tapes had already been mailed and 240 were ready to go as soon as copies of the licenses are received. 
All V7 and V32 tapes for which license copies have been received have been mailed. At the Austin 
meeting three people from UCSD had volunteered to look at the submissions and annotate the tape, 
and Scherrer had been asked to act as chairwoman of the committee. The tape was perused and guide- 
lines for future submissions were drawn up. 


Wedel! stated that financial matters for the Austin Conference were not yet closed out due to 
administrative problems at the University of Texas. 


A tentative date was set for the next Board meeting. A question from Borden as to whether the 
nominees present were invited to future Board meetings prompted a resolution to the effect that they 
were invited but that no expenses could be paid. The meeting was adjourned at this point, to recon- 
vene at 2:00pm Friday Jan. 29th, 1982. 


Present at this session were all the Board, the nominees and Randy Frank. 


The first item was a report from the committee that was set up to meet with representatives of 
/usr/group. /usr/group wanted to equally share both time and income, and also realize money towards 
operating expenses. There was a lot of discussion as to how time could be distributed, whether parallel 
sessions were feasible, the effect on the Software Tools group, and division of expenses and income. 
The Board was split on the issue as to whether to proceed with a joint meeting in Boston but finally 
passed a resolution to go ahead, setting up a committee to work out the details with /usr/group. 
Material and statements relative to the divergent positions of the board members on this matter will be 
published in the next issue of ;/ogin. It was felt that if there could be cooperation under what all 
agreed were possibly going to be difficult circumstances, it would auger well for the future. It was sug- 
gested that a questionnaire be circulated to all attendees at the meeting just finished and all members, 
asking for feedback on the conference and on the idea of cooperation with /usr/group at the Winter, 
1983, meeting. Law had the outline of a questionnaire and agreed to complete it and, after review, 
have it mailed. [It is part of this newsletter...ed] 


Committees were appointed for the next meeting: Local arrangements and budget - Donnelly 
(chair) and McNary; Technical Program - Nemeth (chair), Ferrin and Scherrer; Tutorials - Borden; 
Publicity - Katz; Vendor exhibits - Donnelly (chair), Nemeth. 


A motion was then made and passed that all expenses incurred on conference business be reim- 
bursed from the conference budget. Discussion then followed on the policy of renting vendor exhibit 
space. It was agreed past exhibitors would have first opportunity, with payment required by a certain 
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date, after which booths will be available on a first come, first served basis. 


The date and time of the next Board meeting were confirmed as Sunday, March 12th, 1982, start- 
ing at 10am, continuing Monday March 15th at 9am and ending no later than 4pm. The location will 
be Boston. 


Law agreed to ferret out information needed to complete an application for insurance to cover the 
Board and Association against liability. The application form he previously received seemed totally 
inappropriate. 


The question of publicity was deferred, as changes in the membership structure are being con- 
sidered, and it did not seem to make sense to recruit members into what seem to be inappropriate 
classifications. Fuchs, Katz and Law have been working on the Bylaws; Katz requested Fuchs to coor- 
dinate the work. 


It had become apparent in the nomination process that availability of travel expenses to Board 
meetings was crucial to acceptance by the nominees to serve. As a result a motion was made and 
passed that expenses for attendance at Board meetings be paid for by USENIX. 


Tom Strong took notes at the technical sessions of the meeting, which after editing, will be repro- 
duced in the January, 1982, newsletter. Several people are interested in producing the newsletter on a 
commercial basis, and have been asked to submit proposals in time for the next Board meeting. Katz 
requested authorization of funds for producing the January issue, and Wedel was asked to give a 
schedule for getting out the missing 1981 issues, possibly combined as one issue. Ferentz asked for 
cost estimates for tax purposes as USENIX operates on an accrual basis, and hence the cost should 
come out of 1981 funds before taxes. 


The first 1982 distribution tape will contain the submittals from the Santa Monica meeting. Six 
tapes have been submitted. The tape committee will attempt to annotate the contents. Ferentz will 
send out release forms almost immediately, and the delays due to the necessary request for copies of 
licenses from the people ordering tapes should not occur this time. 


Six items were dealt with under the heading of Any Other Business, this forming the remainder 
of the meeting. As it was very difficult to generate a meaningful budget to present to this Board meet- 
ing, Ferentz requested a motion of continuation authorizing expenditures at a rate not to exceed those 
of last year. The motion was made and passed. Katz stated he had spoken to AT&T representatives 
concerning USENIX acquiring a license to handle licensed material. AT&T will apparently look into 
and consider this. Law stated that he would like to get out of the manual reproduction and distribution 
business. Ferentz thought that such a service was very necessary, and that USENIX should explore 
alternatives, although the attitude of AT&T towards this is not very clear. Law was asked to write a 
letter to AT&T requesting permission for USENIX to reproduce documentation for other users. 


A vote of thanks was made to all the people who contributed to the success of the Santa Monica 
meeting, in particular John Donnelly, Judy DesHarnais, Peter Weiner and Interactive Systems Corp., 
Mike O’Brien and Dave Martin, the Session Chairman, and Conventions West. 


Groundwork is already being done for the San Diego meeting next winter. Donnelly has asked 
for a proposal from Conventions West, as their performance was impressive at this meeting. Judy 
DesHarnais may be available as the Local Arrangements Chairwoman again, which would be to 
everyone’s benefit. 


Randy Frank of the University of Utah offered to host the 1984 Winter meeting at Salt Lake City, 
Utah, The facilities appear to be good. Donnelly said there are two other offers for the same time slot - 
Phoenix and Portland, Oregon. Proposals from all three sites will be available at the next Board meet- 
ing, when a decision will be made. 


Adjournment was proposed by Scherrer and the motion passed at 8pm. 
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A Questionnaire 


The responses to this questionnaire will be used by the USENIX Association to help plan future 
meetings. A separate answer sheet with pre-printed return address has been provided for your answers. 


Please feel free to reproduce the questions and answer sheet for the use of other interested parties. 


1. Santa Monica Meeting, Jan. 1982 
1. Did you attend the Santa Monica USENIA% meeting? 


A. Technical Sessions 
1, How do you feel about the number of presentations? 
2. How was the length of the day (8 am to 6 pm)? 
3. How interesting were the presentations? 
4. How comfortable was the meeting room? 
5. Should there be parallel sessions? 
6. Should the session format be different? How? 


B. Birds of a Feather Sessions 
1. How should the sessions be organized? 
2. How much time should be allocated for a BOF? 
3. Is there a need for BOFs in addition to those which met at the meeting? 
4, Should a written summary be produced? 
5. What is the optimal number of people for a BOF? 
6. Should the format be different? How? 


C. Other 

_ Is it necessary to distribute a full program (names and titles) prior to the meeting? 
_ Is the list of attendees produced at the meeting useful? 

_ Is the list’s usefulness outweighed by its potential abuse? 

. What else could be done to make the meeting more effective? 

How useful would a list of pre-registrants and their hotels be? 

. When would you like to see abstracts available? 


NAW AWN 


this? 
Should USENIX distribute manuals? If so, which format would you like? 
Should there be conference proceedings? Would you pay extra for them? 


yo 90 


II. /usr/group 
1. Are you aware of its existence? 
2. Do you belong to /usr/group? 
3, Have you attended a /usr/group meeting? 
4. Are you in favor of further cooperation between /usr/group and USENIX? 


III. General 
1. Are you a member of the USENIX Association? 
2. Is your organization a member of the USENIX Association? 


. Early publication of abstracts would impact the timeliness of topics. How do you feel about 
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Answer Sheet for the Questionnaire 


Please circle your answers. Please use a separate sheet for your comments, and reference the 
question number in your comment. When you are done tear out this answer sheet, place your com- 


ment sheet(s) inside it, fold to show the pre-printed address, staple, stamp, and mail. 


I. Santa Monica Meeting, Jan. 1982 
l. yes no 


A. Technical Sessions 
1. far too many toomany right number toofew far too few 
2. far too long toolong right length too short far too short 
3. very interesting interesting acceptable dull very dull 
4. very comfortable comfortable adequate uncomfortable very uncomfortable 
5. yes only if necessary no don’t care 
6. yes no don’t care 


B. Birds of a Feather Sessions 


1. more formal asis more impromptu 
2. less than 1 hour Jl hour 1-1/2 hours 2 hours more than 2 hours 
3. yes no don’t care 
4. yes no don’t care 
5. less than 20 20-30 30-50 50-100 more than 100 
6. yes no don’t care 
C. Other 
l. yes no, but would like to see one no 
2. yes no 
3. yes no 
4. nothing comments 
5. very useful useful waste of paper undesirable 
6. with pre-registration at registration after the meeting never 
7. topic currency more important don’t care early abstracts more important 
8. yes no don’tcare 8-1/2x1l 6x9 
9.yes no don’tcare yes no _ don’tcare 
II. /usr/group 
l.yes no 
2.yes no 
3. yes no 


4. yes no don’t have enough information 
Ill. General 

l. yes no 

2. yes no 


Thank you for your help. 
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Santa Monica USENIX Meeting Notes 


Scribes’ Note 
Tom Strong, Strong Consulting, 5706 Van Fleet Ave, Richmond, CA 94804 


I was not able to attend all 67 talks so some are not adequately covered below. Copies of the 
viewgraph foils, abstracts, and/or papers were used, when available. The abstracts and papers were very 
helpful in, providing accurate detail and making clear my scribbled notes. Abstracts have been 
requested for the talks on which I have incomplete notes and/or other information; summaries of those 
talks will appear in a future issue of ;login: 


Through these notes various network addresses are given. Inconsistencies in case and form in 
some of the addresses were found so don’t take the addresses given as gospel. 


Corrections to these notes should be sent electronically to 

ucbvax !g:usenix 

or to 
Lou Katz 
541 Evans Hall 
EECS Department 
University of California 
Berkeley, CA 94720 


Introduction Session 


USENIX Announcements 


The next three USENIX meetings are scheduled for July 6-9 at Coptey Plaza Hotel in Boston, San 
Diego in January, 1983, and Toronto in July, 1983. 


UNIX News from AT&T 
Larry Isley of AT&T 


UNIX System III (S3) has been announced. It was described as Version 7 plus PWB plus 
enhancements. It works on the VAX-11/780 and PDP-11/70, 45, 44, 34, and 23. The enhancements 
noted were: new Source Code Control System (sccs) commands, new graphics commands, new 
input/output features, C-compiler improvements, C-library additions, greatly enhanced terminal 
options, bugs fixed in many other commands, and various text processing changes. The text processing 
changes mentioned were a more efficient nroff/troff nroff bold font simulation, an escape feature to 
allow system command execution from within nroffftrafftext, new terminal driving tables, modifications 
to improve portability, and many mm macro enchancements. 


System III licensing fees are: 


first CPU each additional CPU 
83 $43,000 $16,000 
upgrade 32V 6,000 2,000 
upgrade V7 18,000 7,600 
upgrade V6 26,000 10,300 
upgrade PWB 16,000 7,000 
upgrade V6+V7 14,000 6,300 
upgrade V7+PWB 4,000 3,000 


There is one basic software agreement with supplementary agreements, depending on the custo- 
mers needs. Licensing procedures, and the time for each step, are: written request from customer, 
preparation of the agreement by AT&T (allow 2 to 4 weeks), agreement execution and payment (custo- 
‘mer time), agreement execution by AT&T (1 day), and software delivery (allow I to 5 days). 
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As a reminder it was noted that AT&T licenses UNIX as is, with no maintenance, no warranties, 
no patent indemnification, no trial period, and with payment in advance. 


The numbers of UNIX licenses and installations are given in the following tables. 


Licenses 

Commercial Educational Government Total 
M-UNIX 6 113 0 119 
V6 90 346 50 486 
PWB 46 56 63 165 
V7 129 277 41 447 
32V 73 132 15 220 
$3 3 0 0 3 
Totals 347 924 169 1440 

Installations 
Commercial Educational Government Total 
M-UNIX 8 339 347 
V6 157 904 129 1190 
PWB 113 192 70 375 
v7 172 795 38 1005 
32V 96 228 15 339 
$3 3 0 0 3 
Totals 549 2428 252 3229 


The licensing agent is 
Technology Licensing Manager 
American Telephone and Telegraph Co. 
P. O. Box 25000 
Greensboro, North Carolina 27420 
919-697-6530 


An Error in System III VAX Booting Instructions 


[A note from an unrecorded source that I hope I wrote down correctly...Scribe] In the VAX con- 
sole commands to be used in bootstrapping "s 2" should replace "s 0" to cause the CPU to jump over 
the register save mask (2 bytes) at the front of the program. 


Whitesmiths’ Developments 
Mark Krieger of Whitesmiths 

Whitesmiths has announced release 2.1 of their C and PASCAL compilers and of IDRIS'™. 
Machines supported are the LSI-11, PDP-11, 8080, Z80, VAX-I1, and 68000. Changes include fixes to 
all known bugs, additional basic math functions, ADA-style exception handling for "enter" and "leave", 
improved code generation, and improved VAX and 68000 support. 

PASCAL conforms to the complete 1SO (draft) standard plus providing support for separate com- 
pilation. Modules can be linked to C or assembler code. A validation suite report is available - it 
currently fails one test. 

IDRIS is intended for machines too small to run V7/S3, it runs on the PDP-11, MC68000, and 
8080. It is similar to V6 and has most UNIX utilities. A W7-type file system will be coming with 
VAX-IDRIS. 

Whitesmiths offers new releases of all its products every nine months. Release 2.2 is due in Sep- 
tember, 1982, and will include C and PASCAL for the 8086, Software Tools, and forte, a [irof-like?) 
text formatter. 
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UNIX at Berkeley 
Bill Joy of the University of California 


The Computer Systems Research Group at U.C. Berkeley is directed by Bob Fabry. It is an 
ARPA-funded research group that works on technical enhancements to UNIX on the VAX. They offer 
a VAX 32V tape with their enhancements called 4BSD. Tapes released after the meeting have drivers 
for newer DEC devices, thanks in part to Bill Shannon of DEC. These devices are the TU7 Magnetic 
tape, UDA5O0 disk controller, DN11 auto call unit, and one other. Bootstrap support is also provided 
for the TU7, Holders of old tapes who need these new drivers should contact UCB at the address 
below to pursue the matter further. Currently this tape is available for $300, but the cost will be 
increased soon to reflect the real costs of duplication. Currently there are about 250 4BSD licensees. 
The tape is under the AT&T license and not in the public domain. 


After a February, 1982, evaluation meeting a document describing future plans will be circulated. 
A new 4BSD distribution is planned for Fall of 1982. It should include local and long-haul network 
support, a faster file system, segmented virtual memory, and interprocess communication. They also 
plan to make available a tape of 4BSD-user-contributed software. A software organization package will 
be offered for preparing the contributions. 


In addition to everything else, they are also working on Fortran, mail, and the user interface. 


The group has been receiving a large number of phone calls lately, many of which are outside the 
scope of their charter as a research group; they ask that you use their help sparingly. They are behind 
on the bug reports but are actively working on them now. Bug reports should be sent electronically to 

ucbvax!4bsd-bugs or arpavax.4bsd-bugs@ berkeley 


You can get information on 4BSD by writing to 
Jeri Kotani 
Distribution Coordinator 
Computer Systems Research Group 
EECS Department 
U.C. Berkeley 
Berkeley, Calif. 94720 

They ask that you write for the information packet, read it and only then call with questions. 


The group is not doing any work on PDP-11’s; it is thinking only along the lines of 32 bit proces- 
sors. 


UNIX at DEC 
Armando P. Stettner of T.1.G. group at DEC’ 


The T.1.G. group at DEC has a V7 distribution tape that is available free with a copy of your 
source license. It supports all memory management PDP-11’s, almost all DEC tape drives and disks, 
and has Bill Shannon’s overlay kernel. In about six months the group plans a new V7 release with on- 
line logging, more device drivers, and an easier way to configure to your PDP-11. Requests for infor- 
mation on the tape, called V7M, should be directed to 

Wendy Murphy 

DEC 

Continental Blvd. 
MK1-1/029 
Merrimack, NH 03054 
603-884-7256 
decvax!wendy 


The UNIX Engineering Group in TIG is headed by James Barkley (decvax!jmb). The group con- 
sists of Armando Stettner (decvax!aps), Bill Shannon (decvax!shannon), Fred Canter (decvax!fred), 
Jean Wood (decvax'jean), and Jerry Brenner (decvax!kjb). The related UNIX Program Planning 


“Also president of the Armando P. Stettner School of Creative Driving 


Volume 7, Number 1 January 1982 11 


slogin: 


Group consists of Rich Ptak (decvax!rlp), Bill Doll, and Tony Godino (decvax!tony). 


What’s Happening at DECUS 
Mark Bartelt of CalTech 

UNIX is now a valid topic of discussion at DECUS. After a lot of discussion the Special Software 
and Operating Systems (SS&OS) SIG has been formed, with UNIX as its primary topic. The SIG has 
about 1700 members and has offered tutorials and other things. It is planning to offer a tape of UNIX 
tools that are not covered by the UNIX license. The following addresses were offered: 


Tape Submissions: Newsletter (temporarily): 
Carl Lowenstein Mark Bartelt 

UCSD P-001 CALTECH 356-48 

La Jolla, Calif. 92093 Pasadena, Calif. 91125 
ucbvax!sdcesvax!mplsahc!cdl ucbvax!cithep!mlp 


Microsoft Overview - The XENIX Project 


Gordon Letwin, Microsoft Inc., The Microsoft Building, 1700 Northup Way, Bellevue, WA 98004, 
decvax!microso!gordon 

Microsoft specializes in OEM system software for micros. They find that BASIC is widely used. 
Among other things they are working on portability of C and PASCAL. They offer the XENIX system 
for micros such as the Z8000, 8086, and 68000. It is based on V7; they will be going to System III. 
XENIX is oriented towards an office environment. 


Future directions at Microsoft include expansion to 32-bit processors, distributed 
processing/networks, and personalized work stations utilizing intelligent terminals, windowing, and 
graphics support. 


European UNIX Users Group 


There will be a meeting April 16 and 17 in Paris(!). The European group may be contacted at the 
following address: 
R. A. Mason 
Computer Engineering 
Heriot-Watt University 
Mountbatten Building 
31-35 Grassmarket 
Edinburgh EH! 2HT 
Scotland 


System Portability Session 


Experiences in Porting Coherent to the Z-8002 
Robert Swartz of Mark Williams Co. 

{I had only the abstract for this talk...Scribe] This talk discussed the methods and strategies that 
were used in transporting the Coherent operating system to the Z-8002. It described the retargeting of 
the Mark Williams C compiler in detail. The design of the operating system kernel and the changes 
required to move it to the Z-8002 were also discussed. A simple and elegant solution to the byte swap 
problem was presented. 
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UNIX on IBM/370 Architecture Machines 
Steven J. Buroff of Bell Laboratories 


[These notes were taken from the foils and abstract...Scribe] They have implemented UNIX on 
1BM/370 architecture machines. These include the 4341, 3031, and 3033 as well as the 370 family 
machines. Full-duplex UNIX terminal support is provided using an IBM Series/1 as a front end proces- 
sor. Remote job entry using the bisync protocol is also supported. The system is running on an IBM 
machine to take advantage of the power and reliability of the hardware and to better access large shared 
databases. The UNIX kernel interacts with the TSS kernel, which supplies the use of various well- 
proven code in TSS. Performance is shown in the following table: 


System Performance 
VAX 1.0 
3033AP 8.2 
3081D 8.7 (est.) 
3081K 12.2 (est.) 


A 3033AP customer currently supports approximately 180 interactive users plus a large background 
load. 


UNIX Front Ends to Large Hosts 
Richard Hyde, 1.C.C.-B.Y.U., 460 N. University Ave., Provo, Utah 84604, 801-373-1313, ICC!rich or 
BYUCS!rich 

This talk discussed front-end machines for batch-oriented machines in general, and their connec- 
tion of an Onyx Z-8002 to an IBM 4341. Assuming the need for a large batch oriented machine, the 
use of a front-end such as UNIX offers a better and more portable development environment and 
reduced cost per terminal. Against this must be weighed the disadvantages of another machine to sup- 
port, or go down, and the cost of transmission between the front- and back-end machines. 

Various networks are possible; they used HASP for remote job entry. They recommend that the 
connection be through a DMA block device, not a character device. The front-end must be able to 
handle interrupts quickly. 

Significant questions about how much the user should have to know about the back-end machine 
were raised. For example, how much should the user have to know of the link? of the host JCL? of 
character translations? 

Several areas needing work for this type of UNIX application were noted: (1) fintlike syntactical 
checkers for other compilers on other machines, (2) JCL-generating programs to convert a "standard" 
form of job control language into its machine-dependent dialects, (3) network topological display tools 
for users, and (4) improved network mail facilities to and from both UNIX and non-UNIX machines. 


Ports of UNIX to the Motorola 68000 
Rick Kiessig, Fortune Systems, 1501 Industrial Rd., San Carlos, CA 94070 

Fortune Systems has ported UNIX to a 68000. Why select a 68000? (1) It’s powerful and rela- 
tively cheap (a little slower than an 11/44, in their experience). (2) 16 MB address space. (3) Family 
growth of the 68000 series, and multiple sources for components. They are using their own bus. 

In the software end, they started with MIT C compiler; it took about 6 weeks to adapt. They 
found that the compiler has about 8-10 bugs and produces optimized code about 15% larger than on a 
PDP-I1, that the loader is not complete, and that the assembler has 2-3 bugs. They found that Whi- 
tesmiths’ C is not really Bell "standard" C and that the code is generally not as dense as from MIT’s C 
compiler. 

Fortune will be offering a 68000-based UNIX system with 256Kb, 5.25 inch Winchester disk, and 
720Kb floppy for around $6000, including a UNIX license. 
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Scattered Main Memory Allocation for Microprocessor-Based UNIX Systems 


Jerry Dunietz, Microsoft, Inc., The Microsoft Building, 10700 Northup Way, Bellevue, WA 98004, 
decvax!microsoljerry 


This talk, and a related paper, discuss the problem of memory management in UNIX. PDP-11 
UNIX allocates one contiguous piece of physical memory for a process’s user page, data, and stack. As 
processes of various sizes die and new ones are created the memory is fragmented. They found many 
cases where a memory allocation request failed because a contiguous block of the required size was not 
available, they also found that on the average over 5 times the required space was free, but that the 
free space was in small pieces. 


They propose a scheme for allocating memory in discontiguous pieces on microprocessors. This 
allows their kernel (XENIX) to use every available page of memory, reducing swapping and memory- 
to-memory moves. 


The disadvantages on systems that do not have hardware features to map the I/O are: (1) swap- 
ping takes one I/O transfer per memory piece, and (2) physical I/O, which bypasses the system 
buffering mechanism, cannot be handled. Their answers to these problems are: (1) it is much more 
important to minimize the need to swap or do memory-to-memory copies than it is to minimize the 
number of I/O operations involved in swapping; (2) processes using physical I/O are rare, and so are 
handled specially and given contiguous regions of memory. 


How to Port UNIX to a Microcomputer 


Alan Whitney, Microsoft, Inc., The Microsoft Building, 10700 Northup Way, Bellevue, WA 98004, 
decvax!microso!arw 


They connect the target machine to an 11/70 over serial lines. The target machine needs 256Kb 
of memory, suitable memory management, a disk (hard or floppy) with at least 5Mb, 2 serial lines to 
the 11/70, a rom monitor, and a breakpoint device. They debug external devices such as the file sys- 
tem and tape by simulating them on the 11/70. The steps they follow when porting UNIX to a new 
micro are: (1) write a stand-alone program for the machine, (2) modify the simulated disk driver and 
Tun it stand-alone, (3) write the memory management <ode, (4) install the simulated disk driver into 
the system, (5) run the kernel test programs, (6) install initand sh, (7) write and debug the hard disk 
driver, (8) download the utilities from the 11/70 and test them, and (9) port the compiler. 


A Dual Processor VAX-11/780 


George Goble, Elec. Engr, Purdue Univ., West Lafayette, IN 47907, 317-494-3545, decvax!pur-ee!ghg, 
arpavax.ghg @ berkeley 

They have put another 11/780 CPU in place of the SBI bus terminator on their WAX. The add- 
on processor runs only user-mode processes, with the original (master) CPU handling all system cails, 
interrupts, and user-mode processes in any left over time. They have found that performance is about 
1.8 times as good as with a single processor VAX, although it can be hurt by many system calls and 
block memory writes. They run a version of 4.1BSD that was modified locally. They typically support 
90-100 users with this system. Their analysis indicates the 2 processors use about 75% of the memory 
bandwidth so a third processor would not offer much. 


Problems encountered, and their solutions, were: (1) memory timeouts were found to be caused 
by cable problems (replacement cables available from AMP have insulators to reduce the problem), (2) 
LSI-11 console integration was surmounted by removing one of the LSI’s; (3) maintenance. 


They found that when a VAX "prober" instruction was executed right before a page boundary 
when lots of I/O instructions were also being executed a machine check would occur. Their solution 
was to put no-ops in to move the instruction past the page boundary. 


{DEC has announced the VAX 11-782 which consists of two 11/780 processors. (However, the 
second processor is not attached to the SBI of the original processor, as above, but communicates via 
shared memory.) It will be available as a field-installable option priced at about $180,000.] 
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Porting UNIX to the HEP: A Modern SuperComputer 
Mike Muuss, US Army Ballistic Research Lab, 301-278-5691, Mike @BRL 


HEP is a 64 bit word, byte addressable, register oriented, 4 CPU, 10-MIPS, 20Mb computer being 
built for BRL. It will be used for interactive high resolution 3D shaded and vector graphics, heavy 
timesharing uses (typesetting, applications, etc.), interactive modeling and analysis codes, number 
crunching, and MIMD algorithm research ("proposals invited"). 


The architecture of HEP is (quite by accident) uniquely suited for UNIX. It will be running the 
BRLNET high performance V6+ kernel. They will start with PCC and put the kernel in 1 CPU anda 
skeleton in each of the other 3 CPUs. Then they will bring in a HEP optimizing C compiler. Utilities 
will be mostly V7. A production system is expected during the summer of 1982. A TCP/IP network 
connection is planned by January. 


A Virtual UNIX for TOPS-20 


Jay Lepreau, Computer Science Dept, Univ. of Utah, Salt Lake City, UT 84112, 801-581-8332 or 8224, 
Lepreau@UTAH-20, decvax!{harpo,randvax} !utah-cs!lepreau 

They are building a virtual UNIX to run under TOPS-20 so they can access the system languages 
and extended addressing of the DEC-20. Their goals are to provide the same file format for both 
TOPS-20 and "VUNIX", to be able to access both environments from C, to keep kernel changes invisi- 
ble to user programs, and to not hack TOPS-20. The order of projects has been to make PCC work, 
then provide a V7 environment, then transport user programs. Major problems encountered include 
the 20’s 36 bit word (standard byte size is 7 bits!), line terminators (CR/LF-LF), long file names, and 
no links. 

They have found that the "portable" C compiler is not particularly portable to word-addressable 
machines. They also found problems with the C language specifications when the target machine is dis- 
similar to the canonical PDP-11 architecture. 


UNIX on the PERQ 
Michael Tilson, Human Computing Resources Corp., 10 St. Mary Street, Toronto, Ontario, M4Y 1P9 
Canada, 416-922-1937, decvaxthcr!mike 

The Three Rivers Computer Corporation PERQ is a high performance personal work station 
intended for management information systems. It uses a high resolution, micro-programmable bitmap 
display [quite impressive to see...Scribe], a 1 MIP processor, Winchester disk, tablet, IEEE bus, Ether- 
net, and writable control store. 

{My notes on this talk were inadequate; look for more information in a future issue of 
slogin:...Scribe] 


Volume 7, Number I January 1982 15 


slogin: 


Performance Issues Session 


Performance and Robustness Improvements to V7 UNIX 


Thomas Ferrin, Computer Graphics Lab., School of Pharmacy, University of California, San Francisco, 
CC 94143 


The Bell release of V7 has been found to be slower than V6. A number of improvements have 
been made and are available as the 2.81BSD tape. The improvements made include: (1) 1024 byte file 
system; (2) the buffer cache was moved outside kernel address space; (3) standard output to terminals 
is "line buffered"; (4) dynamic UNIBUS map allocation for the 11/70; (5) a search pointer for allocating 
free inodes; (6) hashed searching for in-core inodes and buffer headers, (7) inline macros used to cut 
down on subroutine overhead; (8) the process table is searched only to the last active entry; (9) 
reduced overhead on system calls; (10) a faster nameX); (11) optimized freelist interleaving; and (12) 
faster user file descriptor allocation. The graph presented suggested a 3X improvement with 20 users 
and a 2.5X improvement with 42 users. 


A paper is available at the address given above; please include copies of the signature page and 
"definitions appendix" page from the Western Electric license agreement. Information on the availabil- 
ity of the 2.81BSD distribution is available from 

Mary Ann Finnerty 
Computer Science Division 
EECS Department 
University of California 
Berkeley, CA 94720 
or send uucp mail to 
ucbvax!maryann 
Be sure to indicate you are interested in the PDP-11 version ‘2.81’ distribution. 


High Performance File System Routines 


Robert Gray, Pattern Analysis & Recognition Corp., Seneca Plaza, New Hartford, NY 13413, 
duke!ladiron!bob, gray @berkeley 
Dave Bennet, Bell Labs (Holmdel) 


They described a need for very high speed I/O transfers on huge files. The goals were to be able 
to use normal utilities on the files, to do DMA to/from user space, to have it work on PWB, 4.1BSD, 
V7, and 2.8BSD, and to have no kernel changes. They have written a series of routines that allow the 
user to manage an area of the disk through special create, open, etc. calls. The routines interpret the 
superblock and inodes directly. Their measurements on 1Mb files on an RPO6 show significant 
improvements in data transfer speeds. The work should be complete in mid-February, 1982. A 15 
page paper is available by mail at the above address. The software will be available. 


A Communications Co-processor for UNIX 
Mike Zuhl’, MS 92-515, Tektronix, Inc., Box 500, Beaverton, Oregon 97077, teklabs!tekmdp!mikez 


The Tektronix 8560 system is a multi-user UNIX-based microcomputer development system 
named TNIX. It needs lots of communication ability to support terminals with screen editors (RS- 
232), RS-422/423 @ 153.6K baud communication, and other connections. They have produced an 
attached communications I/O processor (IOP) that appears as a superset of the standard UNIX tty 
driver to user programs. It appears similar to disk-to-kernel communication - the C-lists are gone and 
the driver is replaced by a simpler and smaller one. Each IOP will handie 4 ports, in any mix of RS-232 
and RS-422/423. They have found that the use of these IOPs removes about 90% of the communica- 
tion load, yet still will provide throughput of about 2400 baud for single characters. 


a 


“The quote of the day: "Tektronix is very big on 3 letter acronyms; or, as we call them, 'TLAs 
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The IOP performs most of the normal terminal functions, and a few new ones. Each ASCII char- 
acter can be individually programmed as to how it should be echoed and what action it will cause. This 
allows mapping of all kinds of special actions, including "copy character from previous line". Com- 
mands and responses are queued in the IOP, with a flag telling whether the IOP or main processor owns 
the entry. Transaction keys are sent in commands and returned in responses to correlate responses to 
commands. 


The IOP is polled; it does not generate interrupts, It consists of 14K of ROM with about 6400 
lines of C and 1200 lines of assembler, and 14K of RAM with about 3K per port of specific data. The 
hardware consists of 1 board, an 8088 processor, 2 SIOs, and a 4 channel DMA from the SIOs to IOP 
memory. 


Line Disciplines as Coroutines 
Dennis Ritchie, Bell Labs 2C517, Murray Hill, NJ 07974, research!dmr, csvax.dmr@berkeley 


The notion of line disciplines (protocol handlers) in Unix is useful, but done in a restricted and 
complicated way. An experimental version of the system replaces line disciplines, together with the 
device drivers for terminals and networks, with a unified structure of stream processors operating as 
coroutines. Each stream processor has a pair of queues, one each for the read and write direction, and 
for each direction provides a pair of routines. One routine accepts data blocks to be placed upon the 
queue; the other is called asynchronously to process the data on the queue. 


Queue processors are connected dynamically in a bidirectional line between the user process and 
the device driver. For example, a terminal attached through a network would be handled by a network 
device driver, a network protocol processor, and the terminal processor. 

All communication takes place by messages passed between queues. Besides ordinary data, mes- 
sages convey control information such as signals and IO control requests and acknowledgments. The 
contents of messages are passed by reference, instead of being copied, so that good performance can be 
achieved. 


Adapting BRL-UNIX to Support Simultaneous V6 and V7 File systems 
Robert S. Miles and Michael Muuss of US Army Ballistics Research Lab 


BRL chose to support their old V6 file systems when they converted to V7. They did this by 
changing the mount file system call to signal if the file is in V6 or V7 format. The inode tables are the 
same. 


UNIX Edition 7 Implementation for Smaller Systems 
Steve Sanderson, Dept. of Astronomy, University of Texas, Austin, Texas 78712, 512-471-4474 

This talk described the trials and tribulations of bring V7 up on an 11/45 with only 64Kw of 
memory. Normally, V7 needs at least 128Kw of memory. They made V7 fit into their machine by: (1) 
reducing the size of the kernel to 16Kw, partly by making a dynamic buffer scheme where the buffers 
are gotten from and released to user space; (2) changing the loader so it fits in the top end of available 
memory instead of above 64Kw. 
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Networking Session 


CCITT Recommendation X.25 and Its Implementation 
Justin Walker of Interactive Systems Corp. 


(These notes are taken from the foils and abstract...Scribel This talk described the X.25 network 
protocol and Interactive’s implementation of it. X.25 defines the mechanisms for a host to interface to 
a public data network, such as Telenet or Tymnet, using various levels of protocol. There are 4 levels 
of protocol defined: electrical, link, packet, and the interactive terminal interface. At the electrical level 
are such things as the shape of the plug. At the link level are things such as synchronization flags and 
framing and error control. At the packet level are such controls as multiplexing and sequencing infor- 
mation. 


Interactive offers its INcard product family for support of various types of networks. It includes 
RJE with Hasp and Bisync, interprocessor links with IPL/x and MIPL, X.25, and a Xerox 9700 inter- 
face. X.25 uses a normal UNIX open, close, read, write interface. They have now implemented 3 lev- 
els of the X.25 protocol and have it in test. 


The host side of the interface has been implemented on the ACC UMX-Z80, a Z80-based DMA 
interface to the UNIBUS. The implementation is one of several communications implementations on 
the UMC, using a common interface to UNIX. 


[The last foil has the line "System suitability: UNIX not a communications host". I did not hear 
the comments about this so leave interpretation of the quote to the reader...Scribe] 


TCP/IP Implementation 
Bruce Borden, 3COM Corp. 
[I have no notes, foils, abstract, or paper for this talk...Scribe] 


The Implementation of a Campus Network 
Jun Murai, Dept. of Mathematics, Keio University, 3-14-I Hiyoshi, Yokohama 223 Japan 


This talk described the Keio S&T Campus Network at the Science and Technology Campus of 
Keio University. It connects 5 PDP-I1/23’s and one PDP/60 running V7 using the "Acknowledging 
Ethernet" scheme. This scheme adds a built-in packet acknowledgment mechanism to Ethernet, while 
preserving the low cost. An Acknowledging Ethernet Interface Unit (AEIU) on each machine incor- 
porates the transport and lower layer functions in it. This provides quick and reliable communications 
and minimizes the software burden in each host. User access is through a shell compatible but rela- 
tively network-transparent interface. The network provides file transfer, RJE, mail, remote terminal 
connection and special device sharing. It runs through a 1 Km coaxial cable at 6 Mbps. 


Each host system has 4 levels of interface to the network. The AEIU driver makes connections 
and does I/O of packets between Ethernet sockets. Various C level system calls have been imple- 
mented to establish connections and send and receive messages. Encryption and decryption are sup- 
ported in a third level. User access to the network is specified by suffixing @ site-id to a login name or 
path name. They have also modified cp, mail, and write to accept "@" themselves. For example, 

% command|@site-id] arg1[@site-id] arg2[@site-id] ... 
% cp prog.c@ss23 b.c 
% Ipr@ea23 text 
% login yoko@ss69 
There are also network status commands. 


A redesign effort is currently underway to implement: (1) more software in kernel space and use 
an overlay kernel, (2) a more powerful user interface, (3) inter-network functions to connect to other 
local networks, and (4) terminal interface processors and file and print servers. 
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Host-Remote: A Satellite Processor System 


Charles R. Price, Storage Technology Corp. MD 3T, 2270 So. 88th St., Louisville, CO 80027 303-673- 
5698 


Host-Remote is an implementation of a V7-based satellite-processor system for PDP-11’s. It is a 
software system to execute and control a user program in a satellite processor connected to a UNIX 
host. This system is similar to that described by Lycklama and Christensen in the “Bell System Techni- 
cal Journal". 


The remote has a minimal control program to provide communication with the host. System calls 
from the remote program are transmitted back to the host for servicing. In the host there is a remote 
link driver in the kernel and a remote coordinating process to handle the system calls and catch and 
perform actions on host signals to the remote. 


The remote processors are typically LSI-11/2’s and /23’s with 60 Kb of memory. They are used 
for real-time applications and may or may not have a terminal attached. Remote programs are compiled 
in the host as if they were standard programs. They are linked in a special way to provide for the 
memory layout of the remote processor. A user logs in and calls the host control program to download 
the remote program. If necessary, the user can debug the remote program by using a slightly-modified 
version of adh 


The use of this system has allowed real-time applications to be developed in the friendly UNIX 
environment. Future directions indicated are towards non-PDP-11 remotes (or hosts!) and a better 
teal-time non-UNIX system interface. 


The wucp Communications Protocols Explained, or uucp on a Z80? 


Lauren Weinstein, POB 2284, Culver City, CA 90230, 213-641-6300 lauren@ucla-security, 
ucbvax!ucla-s!lauren 


This talk described the internals of the uucp protocol. The protocol is not openly documented; the 
papers that do exist do not accurately reflect the production versions of uucp Information from the V7 
manual and available papers was not repeated in the talk. The information presented came from direct 
conversations with the authors of the various uucp segments and experiments, not from the UNIX 
code. 


A basic implementation of the uucp packet driver has been written independent of the Bell code. 
It is written in BDS C for the 8080/Z80 and runs on CP/M'™ and MARC". It can run half duplex at 
high or low speeds. 


[The following notes are taken straight from the foils presented with the talk. Errors in copying 
are mine...Scribe] 


Opening and protocol selection 

Assuming no “security” sequence and only packet protocol "g". [A security sequence, if it existed, 
would be a request for call-back validation. "g" is the standard protocol; others may be negotiated.] 
<nul>:0, <syn>:020 


slave: <syn>Shere<nul> 

master: <syn>S<sitename> -Q0<null> 

slave: <syn>ROK<nul> 

. <syn>Pg<nul> [request to use protocol "g"] 
master: <syn>Ug<nul>  [response: use protocol "g"} 


slave sends inita until inita from master 
slave sends initb until initb from master 
slave sends initc until initc from master 
protocol is on! 


8 bit paths are always required. 
Data segments range from 32-4096 bytes: 32" (2k) 
k is a 3 bit number indicating segment size 
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Packet sequences 
packet sequence numbers are constrained to 3 bits (i.e., mod 8) 


Control byte 
bit 76543210 


ttxxxyyy 


tt meaning 

00 control packet 

10 data packet (long) 
1 short data packet 


ol alternate channel! (not used) 

For control packets: 

xxx name yyy 

1 close n/a 

2 i last correct rec. seq. # 

3 srj seq. # to resend (obsolete) 
4 Ir last correctly rec. seq. # 

5 initc window size 

6 initb data segment size 

7 inita window size 


low numbered xxx sent first 

rj = reject (use yyy to update) 

tr = receiver ready 

window size between | & 7 packets inclusive (actually this is max size) 
up to 9600 baud, window size of 2 is optimal if data segment > 32 bytes 
receiver selects segment and window size 


long data packet 
<control byte ><data segment > 


short data segment (may have 0 data bytes) 
(difference between data count and segment size < = 127) 
<control byte> <count difference byte > <data segment > 


short data packet 
(difference between data count and segment size > = 128) 
<control byte > <diff. byte 1 > <diff. byte 2> <data segment> 
diff. byte 1 has high bit on, then low 7 bits of diff count 
diff. byte 2 has remaining bits of diff count 


Note: for short data packets, unused bytes of data segment are always sent and are always check- 
summed. 


After initial synchronization 

Receiver sends mod 8 [incremental?] counter "R"=0 

Sender sends similar counter "S"=1 

R always equals the number of the last correctly received packet 
S is the packet sequence number of the next packet to send 
W=window size (may be different for each sender if desired) 


Sender transmits seq. # packets in range S to (S+W-1)mod 8. 
Receiver expects seq. #’s in range (R+1)mod 8 to (R+W)mod 8. 


Packets must arrive in seq. # order and will only be ACK’d in order. (Next packet receiver will accept 
is (R+1)mod 8.) Receiver ACK’s receipt of packet by sending its R value to sender, where it updates 
senders S value. If bidirectional flow, can be sent as yyy value of data packets (control byte). Other- 
wise, sent as yyy value of rr control packet. 


If receiver detects error, it can: 
a. rely on transmitter (sender) timeout and retransmission, or 
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b. send rj packet. [rj is a selective NACK packet] The rj yyy field replaces S value of sender and is a 
request for retransmission starting at that sequence number. ("go-back-N"[?]) 

Receiver ignores duplicate packets. (The packet driver was originally an experiment at "cleaning" up 

X.25.) 


Most UNIX systems use segment size=64, window =3. 


Framing for asynchronous serial lines 
<syn><k><c0><cl><c><x><data segment, if any> 


magic = 0125252 
<syn>: 020 
<k> (log, segment size)-4, i.e., 1<=k< =8 
If (k=9) this is a control packet with no data segment 
<c>: control byte 
<x>: <k>*<c0>*<cl>"<c> — [* means XOR] 
<c0>: low order 8 bits checksum 
<cl>: high order 8 bits checksum 


Checksums (checksum is 16 bits) 
For control packets: checksum = magic - <c> 
For data packets checksum = magic - (chksum segment” (0377&<c>)) 


Packet driver checksum (from early packet driver doc but still accurate) 
chksum (s,n) 
register char *s; 
register n; 


register short sum; 
Tegister unsigned short t; 
register short x; 


sum = -l; 
x = 0; 
do { 
if (sum < 0) { 
sum <<= 1; 
sum ++; 
} else 
sum <<= 1; 
t = sum; 


sum += “s+ + & 0377; 

x += sum‘n; 

if (Cunsigned)sum <= t) { 
sum “= x; 


} 
} while (--n > 0); 
return (sum); 


Typical file transfer 

master: S /s/lauren/test /tmp/test lauren - D.randvaxn5672 644° 
S means send 
/s/lauren/test is source name 
/tmp/test is destination name 
lauren is the user name 
- is a hyphen 
D.randvaxn5672 is the data file 
644 is the source file mode 
> is an apostrophe 
and the blanks from the S on are where you see them 
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slave: cy’ 
master: H’ 

slave: HY’ 
master: HY’ 


Packet driver off. See V7 manual for more details on this. 


Status of the Network News System 


Mark Horton, Bell Labs, Room 2C-249, 6200 E. Broad St., Columbus, Ohio 43213, 614-860-4276, 
ucbvax!cbosgd!mark, mark @berkeley 

Matt Glickman, Computer Systems Research Group, Evans Hall, University of California, Berkeley, 
CA 94720, 415-642-7780 (messages), glickman@berkeley, ucbvax!glickman 


Network News, or USENET, is used for announcements, queries, bug reports and fixes, mailing 
lists, ongoing discussions, and interest groups. It started at Duke over wucplinks in 1978. It has grown 
since then, and a new version, version B, has come into use and offers personal newsgroups. Another 
version is being created which keeps follow-ups to articles together and provides a gateway. 


There are lots of different news groups; the one named net.all lists all USENET-wide news 
groups. To join USENET you find a site willing to send you news, get the software, get it running, tell 
your connection to start sending you news, then post an announcement that you exist to the net. You 
can get the software from your contact site or one of these public sources: 

/ust/spool/uucppublic/news/bnews.tar [archive file’s pathname] 
SRC-UNIX (ARPANET) 
chico(UUCP net) 
Brian Redman, BTL WH, 201-386-2884 
decvax(UUCP net) 
Bill Shannon, DEC, 603-884-5044 
If you want to run version B, be sure to get a copy of the released version. Version A from Duke is 
more suitable for small systems. 


Introduction to CSNET 


Michael T. O’Brien, The Rand Corp., 1700 Main St., Santa Monica, CA 90406, 213-393-0411, 
obrien@Rand-UNIX, randvax!obrien David Crocker, Dept. of Electrical Engr., University of Delaware, 
Newark, Delaware 19711, 302-738-8913, 302-738-2405 (messages) DCrocker@UDel 


CSNET is a logical network designed to provide communication via telephones, public nets like 
Telenet, and TCP-based networks. It is NSF funded and is expected to be self-sufficient within 5 years. 
It runs under 4.1BSD on a VAX. 


[My notes on this talk were inadequate; look for more information in a future issue of 
jlogin:...Scribe] 


Virtual Terminals in a UNIX Network 


Gary Crockett, Bell Labs, Naperville, Illinois, 312-979-5981, ucbvax!ihnss!ihidt!gbc 
The work is being taken over by: Alan Hewett, Bell Labs, 6200 E. Broad St., Columbus, Ohio 43213, 
614-860-2675, ucbvax!cbosg!apwh 


This talk described a system where a host talks to virtual screens in a terminal handler, and the 
handler maps from these virtual images to the users real terminal. The host does its reads and writes as 
usual but uses a virtual CRT language for cursor movements. There is a special line discipline to talk 
to the terminal handler to provide multiple logical channels on the link. Special joct/calls are provided 
for special functions such as to get the window size. The user can create and delete windows on 
her/his terminal and specify the host name or function associated with each window. There is also the 
ability to change window size or location, switch control between windows, look back through a window 
history, and change window display characteristics (e.g., to fold or truncate long lines). 
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A terminal handler based on a 68000 can handle several terminals. At least 64Kb are needed for 
each terminal. The terminal driver compares the actual and desired screen images and uses termcap ter- 
minal descriptions and an enhanced version of the curses package to update the users screen. 


UNIX/RSCS Networking 


Joseph Boykin, Computer Science Dept., The Pennsylvania State University, University Park, PA 
16802, 814-865-9723, allegra!psuvax!wizard, PPUVAX1%WIZARD on BITNET 


This talk described connecting UNIX to various IBM systems on BITNET through an emulation 
of RSCS. BITNET is a large network of university machines around Pennsylvania, New York, Connec- 
ticut, etc. RSCS is synchronous, oriented to largish blocks (“1000 bytes), auto routing, and runs at 
9600 baud. Write, mail, file transfer, RJE, and command execution are supported. 


By connecting UNIX through RSCS their machine can appear to the network as a peer host, not 
just a work station. 


Vendor Presentations Session 


[The foils for these presentations were not available to me...Scribe] 


3Com Ethernet Network 
Bruce Borden, 3Com Corporation, 1390 Shorebird Way, Mountain View, CA 94043 


3Com offers a complete UNIX-Ethernet package. They offer transceivers to tap into the ether, 
transceiver cables, controllers for QBUS'™ and UNIBUS'™, and DOD standard IP/TCP software for 
UNIX. The transceiver utilizes standard N-series cable TV connectors (rather than a tap) both to 
reduce EMI and for reliability. The cable speed is 10’ bits per second; maximum size packets sent 
back-to-back go at about 9.6Mbs. 


A wansceiver isolates the connected device from the cable. The QBUS and UNIBUS controllers 
each appear as 32Kb of dual ported memory to the host processor. The memory is logically divided 
into 16 packet buffers, any combination of which may be used for transmit, receive, or main memory. 
A starter package for a QBUS or UNIBUS with all cables, connectors, drivers, etc., runs around $6300- 
$7300, 3Com also has UNET software that works with this hardware; it costs about $5000 for the first 


copy. 


A Description of the YARD Relational Database Management System 
Gary Donnelly, RLG Corporation, 1760 Reston Ave., Reston, VA 22090, 703-471-6860 


YARD is designed for smallish data bases (<~3000 records) like those typically found in the 
office environment. It is well suited for applications such as personal DBMS, and can handle repetitive 
letter generation with variable fields, report writing, etc. The data base itself is a UNIX file. The 
YARD programs can be used as filters. Various programs are provided with YARD including: a rela- 
tional screen editor (oriented to the VT100), programs to search, manipulate, and audit the data, and 
an interface to nroff 


Sequitur 
Joaquin Miller, Pacific Software Mfg. Co., 2608 Eighth Street, Berkeley, CA 94710 


Sequitur'™ is a fully relational data base system that runs on V7 and most V7 look-alike 16-bit 
systems. All communication with Sequitur is through a single user interface. A full screen editor is 
used to make entries or changes. The Sequitur system combines relational completeness according to 
Codd with the best features of Zloof’s query by example. Selections use the concept of entity. This 
concept allows the same data to be viewed in different ways depending on the query. The result of a 
relational operation such as selection is a virtual table that may be displayed just like any other table. 
Changes in the virtual table are also made in the underlying table from which the data came. 


Volume 7, Number 1 January 1982 23 


jlogin: 


Sequitur includes integrated text processing, sort, report generator and form letter generator. The 
editor automatically inserts nroffcommands into the text. It is available primarily through OEM’s. The 
cost ranges from about $3500 on ONYX to about $9000 on PDP-11’s larger than an 11/45. 


A UNIX-like, CP/M-compatible Operating System for 8080/Z80 Microcomputers 
Lauren Weinstein, Vortex Technology, POB 2284, Culver City, CA 90230, 213-645-7200 

MARC" is a UNIX-like operating system that was designed to fill the gap between CP/M and 
UNIX for 8080 and Z80 microcomputers. MARC is initially booted up under an existing CP/M system 
(either single-density 1.4 or any version 2.x CP/M). MARC then absorbs the CP/M Basic I/O System 
(BIOS) and becomes a separate operating system, completely independent from CP/M itself. MARC 
needs at least 48K (but not more than 64K) of memory and will run with either hard or floppy disks. 

MARC will transparently support the vast majority of existing CP/M programs. In particular, pro- 
grams which access CP/M system calls via the “standard” low memory calling sequence will generally 
run. 

MARC has a UNIX-like file system and command interpreter. It supports I/O redirection, “wild- 
cards", shell scripts, and pipes. A modified BDS C compiler, oriented towards the MARC environment, 
and a complete set of system calls are provided. There is also a large set of utilities. An optional 
CRT-oriented display editor, patterned after the EMACS editor, is available. 

Tentative pricing for the binary, in single quantities, is $250[!], including the BDS C compiler. 
The dispiay editor, MINCE, is tentatively priced at an additional $100. Delivery media will probably be 
4-5 single density floppys. The exact date of availability is (not recorded...Scribe]. 


Microsoft XENIX 
Gordon Letwin of Microsoft 
[I have no notes, foils, abstract, or paper for this talk...Scribe] 


The PasPort Cross-compiler System 
Morris E. Kranc, Intermetrics, Inc., 733 Concord Ave., Cambridge, Mass 02138, 617-661-1840, x2388 


[I had the foils for this talk...Scribe] This talk described a system to develop and test software for 
dedicated microprocessors in a UNIX environment using PASCAL. The typical target processor is 
"embedded" in some larger hardware system and does not provide a suitable environment for software 
development. 

With the PasPort system microprocessor software is created in PASCAL in the friendly program 
development environment of a minicomputer (PWB, V7, V32, RSM-11M, VMS). The PasPort com- 
piler front end translates PASCAL into an interactive form similar to P-code. The back end generates 
assembly code for the target machine (INTEL 8086 using INTEL MCS 86 assembler or MICROTECH 
ASM 86 assembler or MOTOROLA 68000 using MICROTECH assembler). This assembly code may 
be assembled on the host or the target. The PasPort compiler is ISO (draft) standard PASCAL compa- 
tible plus offering separate compilation and shared global data. 


In the host the program can be executed interpretively from the intermediate language. Various 
Tun-time tools are provided. Host to target communication is provided over a RS-232 line. 


The cost is approximately $5000, depending on the host and options. For more information con- 
tact Rosemary Jenseth at the address above. 
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HCR: Products, Services, UNIX ports, and Future Directions 
Mike Tilson of Human Computing Resources Corp. 
[I have no notes, foils, abstract, or paper for this talk...Scribe] 


LOGIX - Relational] Database Management for UNIX 


Douglas I. Kalish, Logical Software, Inc., 1218 Massachusetts Ave., Cambridge, MA 02138, 617-864- 
0137 


[I have only the abstract for this talk...Scribe] LOGIX provides a set of tools for integrated 
interactive and programmatic database management. With LOGIX a user can define relations, enter 
and edit data, create new relations, and select items from a relation according to complex conditions. 
Logix also provides user-specifiable integrity and authorization constraints on the items of a relation. 
Items of a relation may be marked with a time stamp, providing a history of all changes. If errors are 
discovered in entered or deleted items a relation can be “rolled back" to a time before the changes were 
made. 

The Q Programming Language is provided for processing queries, updating relations, and writing 
reports. Three dialects of Q are offered, including a query language compiler which pre-compiles 
queries into linkable object modules that can be bound together with C functions to produce data 
management programs. LOGIX commands may be freely mixed with UNIX commands through I/O 
redirection, pipes, and filters. 


LOGIX is available now for the ONYX C8002 for $5000, and will be available soon for the PDP- 
11 series. 


Word Processing Session 


Litigation Support 
John Levine, Interactive Systems Corp., 52 Shepard Street, Cambridge, MA 02138 


This talk described a system being developed for lawyers to keep track of internal legal docu- 
ments. It will be able to store documents, search for keywords, dates, words or phrases (in the manner 
of fex{?]), and do flexible report generation, including customizing of formats. The retrieval system 
will be menu driven. Report generation will follow the dictum of "what you see is what you get". The 
system is expected to be available this summer. 


j- Just an Editor 


Carol Tozer, Ivie Computer Corp., 460 N. University Ave. #1, Provo, UT 84601, 801-373-1313, and 
Computer Science Dept., 230 Talmage Building, Provo, UT 84602 


This talk described the implementation of a full screen editor that emphasizes power through sim- 
plicity. The simplicity of the editor allows substantially better machine utilization that existing editors 
with similar features. For example, viuses 2-4 times as much CPU on every benchmark they ran. The 
editor utilizes a split-file internal representation of files and an "input module" - "editing machine" - 
"screen module" organization. The former yields the CPU gains mentioned and the latter facilitates ter- 
minal and user-interface independence. j uses a file to define the characteristics of the keyboard. The 
editor uses fermcapand runs on V32 and VMS and the Z8000 and 68000, 
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The Automated Office as a Management Tool 


Mary Ann Jackson, M.A. Jackson & Associates, 372 N. Bundy Drive, Los Angeles, CA 90049, 213- 
476-4168 


The automated office covers a variety of functions from database management to MIS systems to 
networking to specific applications such as mail, calendar scheduling, and text processing. The talk dis- 
cussed the results of a study done of the time used by various levels of management and their support 
personnel in the areas that an automated office might be used. They found a potential time savings of 
20% would be possible by automating just the specific applications. Equiptment and system criteria 
were established and a pilot program is being installed at the establishment where the study was done. 


The things that the managers interviewed wanted automated were: data base interface, project 
management, mail, individual data bases, word/text processing with document transfer, calendar and 
scheduling, file management, and, lastly, graphics. 


Hum - A Concordance Package for UNIX 


Bill Tuthill, Computing Services, University of California, Berkeley, CA 94720, g.tut@berkeley, 
ucbvax!g:tut 

This talk discussed a package of programs for literary and linguistic computing. They are particu- 
larly useful for the preparation of concordances’ and supporting documents. Both keyword-in-context 
and keyword-and-line generators are provided, as well as exclusion routines, a reverse concordance 
module, formatting programs, a dictionary maker, and lemmatization facilities. There are also word, 
character, and digraph frequency counting programs, word length tabulation routines, a cross reference 
generator, and other related utilities, The programs are written in C and implemented on several V7 
systems at Berkeley. They have been ported to a 4BSD VAX and an Onyx system. They should be 
portable to any system having a C compiler that supports some kind of pipe mechanism. 


Use of the package on various languages, the -ms macro package, and fermcap were shown. The 
following names in termcap were shown to occur more than once: 2621, 300, gsi, and teleray. 


There was also mention of some bugs fixed in refer and an improved version of -ms that loads fas- 
ter because it loads only the commonly used things and .so’s the other things only when needed. 


Another New Text Editor 


Michael D. Tilson, Human Computing Resources Corp., 10 St. Mary St., Toronto, Ontario, M4yY 1P9 
Canada, 416-922-1937, decvax!her!mike 

This talk described a new screen editor that is oriented to good typists. The editor is always in 
input mode; other operations are done with escape functions. The basic elements of the interface are: 
control functions for cursor positioning, the cursor is always in a position to replace the last item 
erased, a “multiply” function to increase the size of the unit to be operated on (e.g., from a character to 
a word to a line), and escape functions to perform other operations, 

The design features include terminal independence (using termcap), very simple user interface, 
compatibility with UNIX tools, and a command language for more complex operations. The goal was to 
make it possible for a typist with no prior knowledge of the editor to perform useful work after 15 
minutes of training. The editor is scheduled to be available in March, 1982. 


Hemingway’s Rating by Style and Diction: An Analysis of The Sun Also Rises 


James Joyce of ITS, 415-621-6415 
Bill Tuthill of UCB, 415-642-9801 


Ernest Hemingway’s The Sun Also Rises is widely acclaimed as an example of good modern 
prose fiction. This talk presented information from the Writer's Workbench programs style and dictum 
on the book. These programs are described in Bell Computer Science Report #91 [2]. The printout is 


“an alphabetical list of all the important words of a book or author, with references to the passages in which they occur 
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reproduced below so future users can have something to measure their own work against. 


readability grades: 
(Kincaid) 2.7 (auto) 1.6 (Coleman-Liau) 4.0 (Flesch) 5.7 (92.6) 
sentence info: 
no, sent 7354 no. wds 68551 
av sent leng 9.3 av word leng 3.91 
no. questions 763 no. imperatives 68 
no. nonfunc wds 35087 51.2% av leng 4.94 
short sent (<4) 10% (748) long sent (>19) 8% (594) 
longest sent 197 wds at sent 2737; shortest sent 1 wds at sent 1721 
sentence types: 
simple 75% (5519) complex 11% (843) 
compound 10% (714) compound-complex 4% (278) 
word usage: 
verb types as % of total verbs 
tobe 26% (2964) aux 15% (1692) inf 8% (935) 
passive as % of non-inf verbs 3% (314) 
types as % of total 
prep 9.2% (6295) conj 3.8% (2582) adv 7.4% (5056) 
noun 21.2% (14563) adj 9.6% (6611) pron 14.2% (9824) 
nominalizations 0% (113) 
sentence beginnings: 
subject opener: noun (3401) pron (1976) pos (180) adj (187) art (465) tot 84% 
prep 2% (179) adv 3% (253) 
verb 3% (185) sub_conj 2% (138) conj 1% (72) 
expletives 4% (283) 


Applications Session 


A UNIX-based Image Processing System 


Philip A. Dondes, Lockheed Palo Alto Research Labs, Lockheed Missiles and Space Co., 3251 Hanover 
St., Palo Alto, CA 94304 


This Lockheed Lab has 1 11/44 running UNIX. They run a general purpose image processing 
system called UPIPS on this system. It consists of a DeAnza Image Array Processor and programs and 
FORTRAN. and C-callable subprograms to manipulate images and to utilize the DeAnza. The DeAnza 
is connected directly to the UNIBUS and looks like 8Kw of regular memory to the CPU. Access to the 
data is via a phys system call buried deep in the user routines. 


User Psychology 


Elizabeth Howell, Science Applications, Inc., 1710 Goodridge Drive, McLean Virginia 22102, 703-734- 
5960 


This talk dealt with how users (both new and experienced) perceive a computer, and how, from 
this knowledge, to design applications programs that will be used. 

Very naive users seem to feel that the terminal is the computer, that they can "break" the com- 
puter by typing the wrong thing, and that they must respond as fast as the computer does in a dialogue. 
This is in conflict with their need to attain and maintain control of their environment. As the users 
experience increases the desire for control over the computer increases and they often resent messages 
that indicate that the computer is in charge. They also dislike disguising the computer as a person, or 
getting praise from a computer. 


Intelligently planned menus are useful. These displays should be simple, present only one idea 
per display, and should fit the perceptual, cognitive, and emotional characteristics of the people who 
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will be using them. the people who will be using them. Ideally such displays will be as similar as possi- 
ble. Involving a representative user in the design and test phases can help immensely. The conflict 
between novice-oriented easy-to-learn and experienced user-oriented easy-to-use menus can be 
resolved through the following: (1) menu items that show equivalent commands, (2) prompts for com- 
mands that are not entered, (3) allowing short cuts of more that 1 response to prompts, and (4) 2 or 
more interfaces to the same functions. Good menu systems will have the following characteristics: (1) 
a set of standard choices (e.g., help, exit, go back to previous menu), (2) at most 6 other choices per 
menu, (3) a hierarchical system so the user knows where he/she is coming from and where she/he’s 
going, and (4) at most 3 levels (giving a maximum number of menus on the system of 
1+6+ (6X6) =43). 


Error messages should be: clear, specific, concise, brief, polite, comprehensive. They should pro- 
vide positive reinforcement instead of punishment and should be constructive [amen]. For example, 
"date out of range” is much less useful than “date must be in the range 1970-1999". 


A typical user will wait approximately 7 times the average response time before becoming bored 
or panicky. For longer response times it is useful to print a "working..." message. 


Implementation of the 1979 Proposed SIGGRAPH Core Standard for Graphics 
Stephen Daniel, Micro Electronics Center, POB 12889, Research Triangle Park, NC 27709, Duke!swd 


This talk was about work in progress on implementing the 1979 SIGGRAPH proposal core. Their 
work adheres strictly to the proposed standard. The system is two dimensional and supports output to 
level 3b with most raster extensions, and input to level 3, The routines are not written for beginners, 
but do perform extensive error checking. Flexibility has been provided instead of speed, where a 
choice had to be made. A program writes a device independent segment file, which is in turn fed to a 
device driver. Currently the Ramtek 9400 and HP 7220 plotter are supported. The package runs on V7 
and V32. 


Software Scaffolding Management System 


Peter J. Nicklin of the University of California, ucbvax'g.nicklin 
Inquiries should be mailed to 2700 Bancroft Way, Berkeley, CA 94704 


The Software Project Management System (SPMS) provides a convenient environment for up to 
10 programmers working on relatively large software projects in a variety of languages. It will accom- 
modate programmers with widely varying levels of experience, but is still simple to learn and easy to 
use. It has been used extensively for 12 months on a project with about 10 programmers and over 
100,000 lines of Fortran. It runs under 4BSD. 


SPMS uses a project directory hierarchy and commands that know about this hierarchy. It can 
automatically create makefiles for libraries and programs and will provide automatic updating of 
libraries. It provides protection against performing operations in the wrong directories. Progress may 
be recorded via a logging facility. 

There are four types of SPMS commands: environment control, information, file manipulation, 
and program control. 


There are also facilities to tailor SPMS to different programming environments and to change the 
structure of things during a project. There are plans to interface SPMS to sccs 


UNIX-based Environments for Data Analysis and Statistics 


Richard Becker of Bell Labs 
Alan R. Wilks of Princeton University 


People attempting to do data analysis and statistics need a variety of tools and statistical tech- 
niques. A new package called S has been developed at Bell to fill this need, and is available. 


The S system is designed for doing data analysis, particularly exploratory analysis, and for doing 
research on new techniques in statistics and statistical computing. It emphasizes interactive analysis and 
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the use of graphical techniques. Its design reflects both the statistical interests of S’s users at Bell and 
many current ideas in computer science. 


The main strengths of S are the simplicity and generality of the language, the emphasis on 
interaction and graphics, the automatically-maintained, self-describing general data structures, and the 
facilities for the extension of S to new techniques. S is not designed around special classes of statistical 
problems; rather it provides a software environment in which extensions to new areas should be 
straightforward. 

S will run on largish V7 and later UNIX systems. A VAX is preferred, although it will run on an 
11/70 or 11/45 with limitations on the size of single datasets. The system needs to have roughly 
10,000,000 bytes available to hold the S system. It is very desirable to have some reasonably high- 
quality graphical hardware; the S user’s manual lists supported graphics devices. 


A request form and agreement for obtaining S are available from: 
Bell Laboratories 
Computer Information Service 
600 Mountain Ave. 
Murray Hill, NJ 07974 
A tape, user’s manual, and installation instructions will be provided in return for payment of a service 
charge of $150. The user’s manual can be purchased separately for $25. 


ABCD - A Better Circuit Description 


Jothy Rosenberg, Microelectronics Center, POB 12889, Research Triangle Park, NC 27709, 
duke!menc!jothy 


ABCD is a symbolic circuit design language for describing the structure and physical aspects of 
integrated circuits. It is based on a “virtual-grid" layout methodology. It provides a one-to-one 
correspondence between one line of the language and one circuit element, making interactive editing of 
circuit descriptions possible. The language has been implemented in a suite of library routines accessi- 
ble to all design tools in the system. This implementation technique has been fruitful since all pro- 
grams use the same parser and related routines. 

A designer work station consists of a VAX with 2Mb of memory and 30Mb of disk, a high- 
resolution color graphics system with an attached data tablet, and some alphanumeric terminals. A 
designer manipulates his/her design almost exclusively via the data tablet using a menu-driven interac- 
tive graphics editor. 


Blit: A Graphics Terminal for UNIX 
Rob Pike, Bell Labs 2C521, Murray Hill, NJ 07974, ucbvax!research!rob, CSVAX.rob@berkeley 

Blit is a 800x1024 bitmap terminal with a graphics mouse. It contains an MC68000 CPU with 
256Kb of RAM and 24Kb of ROM. It does not have hardware graphics support or 2 disk or bus or 
backplane or memory management or a network interface (but one may be added). What it does offer 
is a reasonable terminal that can be programmed to do what you want it to. It is programmed in C 
which is compiled with mcc (which is being released). Blit can put several independent "layers" (win- 
dows) on the screen at once. Each layer is asynchronous. 


The lessons learned in this project are: (1) graphics can be cheap, (2) the right software can do it 
all, if the hardware is designed with the software in mind. 
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Languages Session 


An EDISON Implementation Under UNIX 
Bruce Carneal, c/o WICAT, POB 539, 1875 South State, Orem UT 84067, 801-224-6400, x231 


[I have only the abstract for this talk...Scribe] This talk described an implementation of the 
EDISON language using /ex and yacc It focused on the interface between existing UNIX tools and a 
retargetable code generator developed at the University of Wisconsin at Madison. The code generator 
uses an attribute grammar based machine description to achieve portability and tight code. Also dis- 
cussed were problems encountered implementing the concurrent programming features of EDISON and 
their possible grafting into C. 


Installation of the FORTH Programming Language Under UNIX 
Rod Schiffman, c/o 230 TMCB, Computer Science Dept., Brigham Young Univ., Provo, UT 84602 


FORTH features an integrated programming environment and operating system. Although it was 
originally designed for programming process control applications, it has begun to find acceptance for 
many other applications. A FORTH interpreter{?] is normally written in assembly language and run on 
a dedicated machine, not under an operating system. Because of the threaded nature of coding FORTH 
words, up to now there has not been a faithful version of FORTH using a high-level language. The use 
of C and the tools available under UNIX have allowed the creation of a transportable version of 
FORTH. They found that they really needed an abstract data type. 


Interpretive Parsing of Procedure Invocations using YACC 


Berry Kercheval, Zehntel, Inc., 2625 Shadelands Dr. Walnut Creek, CA 94598, 
decvax'sytek!zehntel!berry 

An application required the implementation of subroutines in an interpreter. When a subroutine 
is encountered the seek offset for it is stored in a symbol table. When a subroutine is called the /ex 
buffer is cleared, the current position is stored on a stack, and then a seek is done to the beginning of 
the text of the routine. When the routine is done the address of the call is pulled off the stack and a 
seek back is done. Forward referencing is not allowed. 


Sign Extension and Portability in C 
Hans Spiller, Microsoft, Inc., The Microsoft Building, 10700 Northup Way, Bellevue, WA 98004, 
decvax!microso!hans 

The definition of the C language has left confusion regarding type casts, sign extension, and the 
char type. This talk discussed these problems and the lack of consistency in existing C compilers. 

Problems arise when converting from a shorter to a longer type: what will the high order bits be 
set to? If unsigned char or inline type casts are used, everything is clear. Unfortunately not all C com- 
pilers support declarations or casts of unsigned types. Further, not all C compilers that support these 
types use the same algorithm for choosing the conversion. 

Bell’s intent, as communicated by Dennis Ritchie to the speaker, is that C sign extend when the 
operand is signed and zero extend only when the source is unsigned. 

Several inconsistencies were pointed out between V7 PCC, V7 C, and S3 C. The solutions pro- 
posed were: (1) change the C Reference Manual to more clearly define chars as signed and unsigned 
chars as unsigned and to better define conversion of types; and (2) for the time being, if you need to 
write portable code do sign and zero extensions explicitly. 
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Creating a Production-Quality Cross-Compller in the UNIX Environment 

Morris E. Kranc, Intermetrics, Inc., 733 Concord Ave., Cambridge, Mass 02138, 617-661-1840, x2388 
This talk described various problems encountered when creating their PasPort System [described 

in an earlier talk]. They found that the UNIX tools were useful for design, development and test, but 

when it came to production the tools needed were too general-purpose and inefficient to be included in 

their end products. 


An Abstract Data Type Facility for the C Language 
Bjarne Stroustrup, Bell Labs, 600 Mountain Ave., Murray Hill, NJ 07974, research!bs 


This talk described the C classconcept. A class is defined using standard C data types and func- 
tions. A class provides a way of restricting access to a structure to a specific set of functions associated 
with it, without incurring significant overhead at compile or run time. Classes are described in Bell 
Computing Science Technical Report #84. They have been in use for about one and a half years. 
They are available to universities [only?], take about 30 minutes to install, and run on the 11/70, 
VAX, 68000, and possibly other machines. They are implemented by an intermediate pass of cc called 
the class pre-processor, which is invoked when the directive #classis found in a C source file, and by a 
run-time library. 


A New Small LISP Under UNIX 
Alan D, Samples, Naval Postgrad School, Code 0131, Monterey, CA 93940 

NAVLISP is a new small subset of LISP written under UNIX. The interpreter came from LISP 
1.5, the functions from Maclisp, and UNIX provided the file system. NAVLISP is seen as an instruc- 
tional tool. It provides a variety of LISP functions and has such system functions as TRACE and 
UNTRACE, SAVE, RESTORE, and memory allocation. Since many system functions normally coded 
within a LISP system are accessible as UNIX processes, NAVLISP is much smailer than conventional 
LISP systems. It is written in C and runs on an 11/50 with separate I&D space, although it takes a 
maximum of 55Kb so could run on a non-separate I&D machine. 


Database Management Sesslon 


The Query Language for the Sequitur Relational DBMS 
Derek Wright of Pacific Software, Inc. 
[I have no notes, foils, or paper for this talk...Scribe] 


The FORMS Subroutlne Package 
Matthew Diaz, Johns Hopkins University, Applied Physics Lab., Bldg. 6-116, Laurel, MD 20707 

The FORMS package is a general purpose set of subroutines allowing simplified input of data 
through screen oriented forms. Applications range from simple menu driven programs to large data 
entry systems. It provides automatic data checking. FORMS has been made terminal independent 
through the use of fermcap 

A form creator creates a layout file with the form as it is to appear on the screen. This is run 
through a program to make a template file. This template file can be edited to specify, for example, the 
case, range, or length of the data to be entered in each field. Three basic subroutines are provided for 
the actual displaying of the form and accepting the data. There is also a program to print the form. 
The package is in daily use by administrators. 


FORMS may be on the distribution tape. 
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Information Change Control System 


Evan Ivie & Rich Hyde, Brigham Young Univ. & Ivie Computer Corp., 460 North University Ave., 
Provo, UT $4601, 801-373-1313 


This talk dealt with the need for a more flexible software change control mechanism and a new 
one, iccs, that they have produced. The objectives were to provide the following: flexible version nam- 
ing, change identification (who, when, why), storage efficiency, access control, sysgen help, prevention 
of accidental deletion, and visibility of changes. 

Iccs has been in use for 5-6 months at BYU and is being used at 2 other locations. It has reverse 
deltas (i.e., an “undo”), a simplified interface, and a tool approach. It is suitable for an individual or a 
project. Future directions will be towards automatic backups, an expanded “undo”, deadlock resolution, 
automatic audits, and file name extensions, 


UTMOST Office Automation System 


Walter D. Lazear, Air Force Data Services Center, The Pentagon, Room 1D988, Washington, DC 
20330, 202-695-3652 


UTMOST is a hierarchical system of user-friendly menus designed to aid the beginning or infre- 
quent user of UNIX, as well as the busy executive. The user progresses through a series of prompts 
until the desired command is completed. 


The menu program reads a script file, prints a tableau on the terminal, and then requests a choice 
from the user. Arguments following the program name are forwarded to the program at execution. 
Prompts and symbolic arguments are supported, along with automatic help file access and escapes to the 
shell. The program has been optimized to make low baud rate use tolerable. 

Part of the impetus behind UTMOST was the fact that UNIX is not particularly friendly towards 
novice and occasional users. Also, the myriad of commands increases training time. UTMOST was 
written for generalized office functions, although it is expandable for specific applications. 


A menu script consists of header lines, choice lines, and a question. The menu program is writ- 
ten in C and is available by sending a tape and prepaid return mailing package to the above address. 


UTRACKITT 


Samuel H. Praul, DEC, 500 Sylvan Ave., Bridgeport, CT 06606, 203-371-6947 
Until May 1, 1982: ITT-PTC, 1600 Oronoque Lane, Stratford, CT 06497, 203-375-0200, 
decvax!ittvax'!shp 

UTRACKITT was developed to keep track of, and respond to, user reported problems. It pro- 
vides a way to let users see what has been done on their problem, and to keep track of all work per- 
formed while solving a problem. 


UTRACKITT is modeled after UCB Mail with problems and tasks taking the place of mail mes- 
sages. A user enters a problem into a system-wide problem file, supplying such information as problem 
type, priority, and a description of the problem. The “problem staff" is notified via mail when a prob- 
lem enters the system. The problem solution is sent via mail to the person who wanted the problem 
solved. A record of all work done on a problem is kept in a separate problem logfile. Problem headers 
(who, what, when) are kept in 2 files: current (unresolved) and archived (resolved). There is also a 
contact file with the name and full address of each person who has sent a problem. 


UTRACKITT is not available now but copies of the manual pages may be requested at the above 
uucp ot US mail address. 
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Review of Netnews BOF Session 
By Andy Tannenbaum, floyd!trb 


The USENET BOF session was much like the USENET itself; some useful information, some 
flames, some hilarity; too much information to digest in one sitting. We were forced to move the large 
audience from a BOF room to the main conference hall, for lack of space. Mark Horton (cbosgd!mark) 
of Bell Labs Columbus took his usual dictator’s stance behind the lectern, and did a fair job of control- 
ling the madding crowd. 


Mark held a short "name the net" contest, no one seemed to have much of a preference, and 
USENET was voted upon as the official name. 


Mark suggested the prospect of net., pers., and ug. newsgroups, for network, personal (netplay?), 
and underground (ugly?) newsgroups respectively. These distinctions would separate news that is 
strictly work related from news that is more frivolous from news that is downright vulgar. We con- 
cluded that we should not make these distinctions until we felt a pressing need. Argument from the 
pro-morality and pro-choice lobbyists was postponed until the session’s end. 


Rob Kolstad (uiucdcs!kolstad) and Ray Eissick (uiucdcs!eissick) of University of Illinois - 
Champaign/Urbana gave the most entertaining (though long) presentation of the conference on their 
replacement for the fledgling Netnews B system. Their systern is based on the PLATO Notesfile sys- 
tem, and has a nicer terminal interface and saner message ordering than Netnews B. The audience 
seemed pretty impressed with the description of the Notesfile system, but the implementation is brand 
new and there were murmurs of skepticism. 


Matt Glickman (ucbvax!glickman) of UC Berkeley talked about Netnews B. This new version of 
netnews is running in gamma test all over the continent and has been doing a respectable, if not bug 
free job. I consider it a public relations faux pas to have revealed both debutantes at the same ball. 

The last part of the session became the much anticipated "Battle of the Network Stars". Lauren 
Weinstein (ucla-s!lauren) alluded to ancient horror stories of the ARPANET concerning censorship of 
wine and phone phreak newsgroups, and how an ounce of prevention would be worth a pound of cure. 
Andy Tannenbaum (floyd!trb) of Western Electric stood in defense of free speech, truth, justice, and 
the American Way; a network divided will not stand, and all that. Andy also gave an impassioned tes- 
timonial about how great netnews is and how it has brought the quality of his life to hitherto unima- 
gined heights. There was much screaming, laughter, and gnashing of teeth. No conclusions were 
reached; after all, the participants were netnews readers. A good time was had by most. 
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1982 Application for New Membership 
USENIX Association 
Individual or Public Membership 


{] Individual ($12, Institution has Source License) 
Institutional Affiliation: 
Nature of Affiliation: 


[] Individual ($12, Institution has Binary License Only) 
Institutional Affiliation: 
Nature of Affiliation: 


[] Public ($12, Not covered by Non-Disclosure) 


Mailing Address (Individual Members must use institution address): 
Name: 


Phone: 


[] Overseas airmail, add $5.00 


[] Invoice required, add $3.00 bookkeeping charge for invoice or receipt 
(] Receipt required 


Check enclosed: $ 


Return completed form to: 


USENIX Association 
Box 8 
The Rockefeller University 
1230 York Avenue 
New York, NY 10021 


(For Institutional Membership or membership renewal contact the Association offices at the address 
above or at 212-570-8934.) 
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